1. Technical Field
The present invention relates generally to data processing systems and in particular to security of data processing systems. Still more particularly, the present invention relates to a method, system and computer program product for providing improved security of applications running on a secure data processing system.
2. Description of the Related Art
The Trusted Computing Group (TCG) specifications define a set of Platform Configuration Registers (PCRs) that are typically implemented in a hardware element called a Trusted Platform Module (TPM). In conjunction with log-files, the PCRs contain information that describes precisely the hardware and software configuration of a system. The characteristics of every unique program run by the system are recorded in the appropriate log-file, and the recorded data “extends” the corresponding PCR.
There are several important characteristics of conventional PCRs. First, the PCR may only be changed by an “extend” operation. The extend operation uses a secure hash of the prior value and the new “extend” value to create the new PCR content. Second, the PCR is order sensitive, e.g., “(extend(a, extend(b,0)) !=extend(b, extend(a,0)),” and the PCR remembers historical information. Third, any program/application that runs on the system is measured and extended into a PCR before the program/application is run in the trust chain that was previously measured before the application is run. Conventionally, the trust chain starts with special code, called the RTM (or Root of Trust for Measurement) that is tied to the System Reset signal. Finally, the PCRs use cryptographic hashing techniques to ensure the PCRs are safe and trustworthy.
FIG. 4 illustrates conventional usage of PCRs according to current TCG specifications. As shown, 16 PCRs (PCR0-PCR15) 405 are provided within the TPM, each assigned to specific software/firmware functions of the computer system. PCR0 through PCR5, inclusive, have specific definitions for their respective contents. As shown, for example, PCR0 is allocated to BIOS, PCR1 to hardware configuration, and PCR5 to boot loader configuration.
Other PCRs are allocated to similar purposes although their precise contents are not always specified. Specifically, PCR8-PCR15, inclusive, are allocated to unspecified uses in the Operating System (OS). Using LINUX as an example of a modem operating system, there are many components (typically around 500) that must be recorded into the eight PCRs assigned to the OS (i.e., PCR8-15). Example components includes kernel, kernel extensions, device drivers, kernel configuration information, device driver configuration information, shared libraries, system services (daemons), executables (binary), and executables such as Java byte streams, shell scripts, and Perl programs, for example.
A special operation called “sealing” protects cryptographic key materials (or any other data) by tying the information to the specific contents of a specific set of PCR values. “Sealing” refers to performing an encryption with system configuration information in addition to the usual cryptographic key. When information is “sealed to a set of PCRs”, the information is not merely encrypted but is further protected against any system configuration change. If the system configuration changes (as represented by a change in the PCR values), the data cannot be unsealed (decrypted). For example, a changed configuration could be a sign of an attempt to hijack the system, such as a “root kit attack” or a virus, and the PCR and log-file changes induced by the change will prevent data from being unsealed and exposed to the attacking agent. Sealing also binds the decryption operation to the specific machine. If a user copies the sealed data to another machine, the data will not be unsealed even if the hardware and software configurations are identical.
In current TCG architecture, selecting the appropriate set of PCRs to “seal to” is very difficult because the PCRs may be changed as the system operates. As significant system events occur, the events are inserted into a PCR (i.e., they “extend the PCR”) thereby changing the PCR's value. For example, running/executing a new program is a significant event and will thus be logged into a PCR. Since, as shown by FIG. 4, there are a limited number of PCRs implemented in hardware (typically three groups of eight allocated to BIOS, a “static” operating system, and a “dynamic” operating system), many unrelated events are recorded in the same PCR, each one changing the previous value of the PCR. For example, all PCI hot-plug and USB hot-plug events will probably be logged to the same few PCRS.
Using the available PCRs, any program that needs to seal data to a PCR must sort through the maze of options to select the proper PCRs for sealing, and this process is sensitive to changes in any or all of the programs (as reflected in the PCR values). In practice, sealing to BIOS PCRs (e.g., PCR0 through PCR5, inclusive) is more practical but this process provides no insight as to characteristics of the OS, which is where a virus is most likely to attack.
Outside the ability to seal to the hardware and BIOS configuration (which is relatively stable), it is extraordinarily difficult to seal to relatively stable PCRs that describe the operating system, software services (Linux daemons, for example), or applications. With some conventional implementations, data can be “resealed” to new configuration values under the proper protocols and conditions, thus handling planned or scheduled system or application changes.
One problem with conventional utilization of PCRs is that the application/system has to choose a particular PCR or set of PCRs and the implied PCR values to which to seal data for later use. This becomes difficult because of the changing nature of PCR values. For example, if programs are run in a different order (e.g., due to external events), the PCR values will be different (due to a further extend of the PCR). If a new program or subroutine is executed, the PCR values will be different than if the new program had not run, even though the program may have no effect on the application. Also, because the PCRs reflect all of the (trusted) history, the PCRs will never return to prior values once changed (at least until the PCRs wrap around the approximately 160 bits within the register). Several solutions have been proposed to address the above limitations in conventional PCR implementation.
A first proposed solution is to seal the same data (e.g., cryptographic key material) to different sets of expected PCR values. For example, a first set of PCR values would represent the normal state, a second set of PCR values would represent the state after an approved USB (universal serial bus) insertion, a third set represents the state after some other approved device is inserted, and so on. Obviously this solution is both cumbersome and complex to administer, as a system administrator or programmer has to plan for arbitrary numbers and sequences of insertion and removal events. Also, each configuration has to be created (instantiated) to complete the sealing operation because most manufacturers do not define the measurement process clearly enough to reproduce it independently, nor do the provided utilities do the calculations for the programmer. This makes it impossible to calculate the new PCR values, so empirical approaches must be used. Since new events change the PCR values and all events are retained from the original bootstrap, this process could require an endless list of permutations and combinations and repetitions.
A second, simpler solution is to seal data to one set of PCR values and allow unsealing under exactly that one configuration. However, that solution fails to account for the dynamic nature of modem systems, which may include software patches, for example. The solution also forces a reboot of the system in order to restart an application because the very act of reloading the application may change the PCR values, preventing the unsealing of data needed by the application.
A third proposed solution is to dedicate a PCR to each application, but that solution quickly becomes impractical because the TPM is usually implemented as a monolithic chip that would need large resources (many PCRs) to handle all the possible applications. This solution would also make the TPM costly to manufacture. Finally, a fourth proposed solution is to provide multiple TPM chips (following the V1.2 specification). However, this solution runs into the same limited-hardware problems noted in the third solution. Also, there remains the unsolved problem of properly synchronizing the multiple TPM chips, especially in the case of the dynamic CRTM (Core Root of Trust for Measurement) model.
In summary, the selection of PCRs for sealing information that is sensitive to basic “pre-boot” environment of a computer system (i.e., prior to start of the Operating System) can be done if the designer is very careful. However, the selection of PCRs for sealing information that is sensitive to the Operating System is currently infeasible and/or unsolved.